## Summary

This PR syncs the latest changes from `stable` into `release/7.64.1`.

## Why is this needed?

A release branch (`release/7.64.0`) was merged into `stable`. This PR
brings those changes (hotfixes, etc.) into `release/7.64.1`.

## Action Required

**Please review and resolve any merge conflicts manually.**

If there are conflicts, they will appear in this PR. Resolve them to
ensure the release branch has all the latest fixes from stable.

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Documentation-only change to the changelog with no runtime or
behavioral impact.
> 
> **Overview**
> Updates `CHANGELOG.md` for `7.64.0` by adding an entry noting the
CardHome button color change (`#25737`).
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
13e2756. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

Co-authored-by: João Loureiro <[email protected]>

…IDGE_CHAIN_IDS (#25808)

- fix: check chainRanking against ALLOWED_BRIDGE_CHAIN_IDS (#25788)

<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->

## **Description**
When new networks are added to the chainRanking remote feature flag in
LaunchDarkly, older app versions that don't support those networks would
still surface them in the UI (destination network pills, source chain
checks). This creates a forward-compatibility gap where users could see
unsupported networks.

This change adds client-side filtering of chainRanking against
ALLOWED_BRIDGE_CHAIN_IDS — the hardcoded allowlist in
@metamask/bridge-controller that defines which chains this version of
the client actually supports. This ensures that chains added to the
remote flag in the future are silently ignored by older app versions
that lack support for them.

<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->

## **Changelog**

<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`

If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`

(This helps the Release Engineer do their job more quickly and
accurately)
-->

CHANGELOG entry: null

## **Related issues**

Fixes:

## **Manual testing steps**

```gherkin
Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]
```

## **Screenshots/Recordings**

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

### **Before**

<!-- [screenshots/recordings] -->

### **After**

<!-- [screenshots/recordings] -->

## **Pre-merge author checklist**

- [ ] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding

Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [ ] I've completed the PR template to the best of my ability
- [ ] I've included tests if applicable
- [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [ ] I've applied the right labels on the PR (see [labeling

guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **Pre-merge reviewer checklist**

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.


<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Touches bridge network selection/enablement selectors, so a mistake
could hide valid networks or incorrectly disable bridging, but the
change is narrow and well-covered by unit tests.
> 
> **Overview**
> Adds a client-side allowlist check (`isAllowedBridgeChainId`) so
`chainRanking` entries are filtered against `ALLOWED_BRIDGE_CHAIN_IDS`
before being surfaced.
> 
> `selectSourceChainRanking` now filters by *both* supported chains and
user-configured networks, `selectDestChainRanking` filters to supported
chains only, and `selectIsBridgeEnabledSourceFactory` now treats a
source chain as enabled only if it exists in the filtered
`chainRanking`. Tests are expanded to cover EVM/non-EVM unsupported
chains and the new source/dest filtering behavior.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
557c0e3. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->


[2726418](2726418)

Co-authored-by: Bryan Fullam <[email protected]>